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The  Florida  Institute  of  Technology  has  embarked  on  a  unique  experiment  to 
develop  an  imdergraduate  curriculum  in  software  engineering.  The  first  year  of 
this  new  program  is  devoted  to  programming-in-the-small  issues,  including 
traditional  progranuning  practices  using  ti\e  Ada  programming  language,  small 
program  design  techniques,  and  program  verification  and  debugging.  In 
addition,  the  concepts  of  formal  syntax  and  semantics,  formal  grammars  and 
BNF,  performance  issues,  abstractions,  and  object-oriented  issues  have  been 
introduced.  The  course  draws  from  the  many  knowledge  units  described  in  the 
ACM/IEEE-CS  Computing  Curricula  1991  Report  [ACM  91). 

The  second  year  of  the  program,  for  which  this  grant  provided  funding  support, 
concentrates  on  programming-in-the-large,  sof^are  engineering  concepts.  The 
focus  of  this  year  is  software  systems  development  using  teams  of  interacting 
persons,  the  tise  of  tools,  contiguration  management,  verification  and  validation, 
testing,  quality  assurance,  and  more  complex  design  tedmiques. 

Two  courses  were  created  to  provide  maintenance  and  development  experiences 
for  teams  of  students.  The  first  course  concentrates  on  maintenance  activities 
using  an  artifact  and  its  associated  development  documentation.  The  second 
course  concentrates  on  software  systems  development  using  Qeanroom 
technology. 

The  innovative  portion  of  this  approach  is  that 

•  it  uses  Ada  throughout  all  course  activities. 

•  it  approaches  software  development  from  a  software  engineering 
perspective  using  a  team  approach. 

•  it  emphasizes  Qeanroom  technology. 

•  it  requires  the  students  to  function  in  an  industrial-style  setting. 

•  it  requires  the  students  to  use  the  controlling  disciplines  of 
configiuration  management,  quality  assurance,  and  verification  and 
validation  as  part  of  ^e  course. 

•  it  uses  an  artifact  as  a  basis  for  instruction,  presenting  the  student  with 
a  motivation  for  the  controlling  disciplines  not  normally  foimd  in 
typical  or  traditional  small  student  projects. 

•  it  requires  most  of  the  knowledge  units  specified  by  the  new  ACM 
curriculiun. 

Unfortimately,  the  results  of  this  experiment  have  not  been  as  valuable  as  was 
hoped.  It  is  unlikely  that  any  other  institution  will  find  this  material  useful  since 
it  is  so  very  much  ^ored  to  the  unique  program  we  have  here  at  Florida  Tech. 
Even  within  that  program,  we  will  need  to  make  some  reasonably  major 
modifications  to  continue  to  use  tiie  material  because  of  the  lack  of  success 
obtained. 


I.  introduction 


The  purpose  of  this  research  was  to  develop  a  sophomore  level  curriculum  for 
software  engineering  using  Ada.  The  sophomore  level  consists  of  three  quarter 
courses  at  the  Florida  Institute  of  Technology  (Florida  Tech)  and  the  curriculum 
was  designed  as  three  courses  of  classroom  instruction  augmented  by 
laboratories.  Since  Florida  Tech  is  converting  to  a  semester  system,  these  course 
were  designed  with  a  view  toward  easing  the  transition  from  the  original  three 
quarter  courses  to  two  semester  courses  reflecting  the  same  course  content.  Our 
purpose  was  to  specify,  design,  and  develop  a  one  year  sequence  of  courses  in 
software  engineering  using  Ada  throughout  as  the  language  of  illustration.  The 
development  of  these  courses  was  scheduled  to  take  place  during  the  period  1 
September  1991  through  13  June  1992,  but  the  period  was  extended  imtil  August 
1993  because  of  the  need  to  refine  our  approach. 

Specifically,  Florida  Tech : 

•  examined  the  issues  in  imdergraduate  software  engineering  and 
attempted  to  specify  the  learning  objectives  for  second  year  students. 

•  designed  a  sequence  of  courses  to  meet  these  learning  objectives. 

•  dev^ped  the  course  materials  needed  to  implement  this  sequence  of 
courses,  including,  but  not  limited  to,  learning  objectives  by  lesson, 
lesson  outlines,  course  outlines,  lecture  notes  for  each  lecture,  team 
exercises  for  the  students,  laboratory  exercises,  laboratory  manuals, 
instructor's  guides,  sample  examinations,  overhead  slides,  and  a 
rationale  for  ^e  courses  as  implemented. 

•  served  as  a  consultant  for  o^er  instructors  interested  in  using  this 
course  sequence. 

II.  Background 

Sophomore  courses  have  been  taught  at  numerous  institutions  for  many  years. 
Courses  targeted  for  computer  science  have  similarly  been  taught  for  many 
years.  However,  software  engineering  is  a  new  field  and  undergraduate  course 
in  this  discipline  have  not  been  widely  available.  Because  of  the  uniqueness  of 
the  program  at  Florida  Tech,  we  were  able  to  take  advantage  of  the  flexibility  of 
our  curriculum  to  tailor  it  specifically  for  software  engineering. 

The  motivation  to  tide  a  software  systems  course  sequence  as  engineering  is  to 
focus  on  the  fact  that  the  courses  have  the  structure,  rigor,  and  formal  foimdation 
embodied  in  such  a  name.  As  with  other  engineering  disciplines,  the  formal 
beginning  must  evolve  from  experiences  of  the  initial  practitioners  [Shaw  90]. 
Orer  time  fundamental  constructs  evolve  and  educational  pioneers  begin  to  put 
in  place  prototypical  curricula.  The  implementation  of  these  curricula  provides 
the  basis,  ultimately,  for  an  imdergraduate  degree  in  the  field.  During  the  past 
several  years,  we  have  seen  the  emergence  of  software  engineering  as  a 


discipline  apart  from  computer  science.  This  can  be  observed  in  the  creation  and 
publication  of  software  engineering  sample  curricula  in  the  ACM/IEEE-CS 1991 
Computing  Curricula  [AQM  91],  the  British  Computer  Society  and  Institution  of 
Electrical  Engineers  report  on  Undergraduate  Curricula  for  Software 
Engineering  [BCS  89],  and  the  SEI  Undergraduate  Curriculum  in  Software 
Engineering  [Ford  90].  Additionally,  the  Accreditation  Board  for  Engineering 
and  Technology  (ABET)  has  recommended  that  all  Computer  Engineering 
majors  take  a  course  in  software  engineering;  a  recognition  of  the  importance  of 
this  Eeld  to  the  computer  engineering  discipline,  as  well  as  an  endorsement  of 
the  viability  and  uniqueness  of  software  engineering  apart  from  computer 
science. 

This  course  sequence  is  founded  on  a  firm  theoretical  foundation  in  which 
programs  are  viewed  as  rules  for  functions  [Mills  91].  It  embodies  many  of  the 
ideas  found  in  traditional  engineering  courses  in  terms  of  hands-on  laboratories 
and  student  acquisition  of  practical  applications  of  this  theory  in  the  lab.  It  is 
also  predicated  upon  the  notion  that  quality  software  can  be  developed 
assuming  that  the  appropriate  controls  are  in  place  during  development  and  that 
usage  testing  tmder  statistical  quality  control  is  performed.  While  much  of  this  is 
language  independent,  the  mechanism  for  demonstrating  to  the  students  the 
application  of  these  ideas  is  the  programming  language  Ada  was  chosen 
after  careful  consideration,  and  in  spite  of  many  difficult  obstades,  because  it  is, 
quite  simply,  the  best  tool  available  for  imparting  the  tedmiques  of  software 
engineering  in  the  coding  phase  of  the  life  cyde.  The  power  of  Ada  used  in  a 
disdplined  environment  can  be  used  to  demonstrate  in  a  tangible  manner  the 
concepts  diat  we  wish  for  our  students  to  learn. 

The  impact  of  this  approach  is  that  students  are  better  prepared  to  enter  the  field 
of  software  engineering.  Many  hiunan  resource  managers  from  industry, 
especially  the  aerospace  industry  that  deals  mainly  in  government  contracts, 
have  told  us  that  they  would  rather  hire  engineers  from  virtually  any 
engineering  disdpline  and  train  them  in  software  development,  than  to  hire 
today's  computer  sdence  graduate.  The  reason  is  that  the  engineering  students 
imderstand  effidency  and  tradeoffs,  and  are  generally  more  disdplined,  than 
fiieir  computer  sdence  peers.  Further,  it  is  our  analysis  that  computer  faience  is 
better  suited  for  programming-in-the-small  issues  than  for  the  programming-in- 
the-large  issues  that  are  typical  for  the  large  aerospace  organizations.  Thus,  the 
time  is  right  to  transition  the  technology  gained  by  experience  to  incoming 
students  to  better  prepare  ttiem  for  file  chi^enges  of  Uuge-scale  software  systems 
development  We  believe  that  students  should  leave  behind  the  notion  of  joriting 
programs  to  embrace  the  concept  of  developing  software  systems.  While  we  do  not 
want  to  be  viewed  as  a  training  organization,  we  must  nevertheless  be  pragmatic 
in  our  approach  to  education. 


III.  Procedure 


We  felt  that  the  major  emphasis  in  the  new  program  implied  moving  from 
programming-in-the-small  to  programming-in>the-large.  liiis  meant  that  after 
having  spent  the  freshman  year  learning  about  programming  concepts  at  the 
single  programmer  level,  with  programs  requiring  the  students  to  work 
independently,  we  felt  that  students  needed  to  be  brought  together  and  be 
taught  to  work  productively  as  part  of  a  team.  The  sophomore  year  of  the 
computer  science  curriculum  at  Florida  Tech  current  consisted  of  three  quarters, 
although  the  planning  for  these  course  sequences  considered  the  foct  that  in  1993 
Florida  Tech  changed  to  a  semester  program.  Thus,  one  and  one  half  quarters 
was  the  target  of  each  of  the  courses  described,  so  that  the  transition  to 
semesters  wUl  be  seamless.  Therefore,  the  first  course  (actually  one  and  one  half 
quarters)  was  initially  devoted  to  maintenance  of  large  (to  the  students)  software 
systems,  while  the  second  course  (again,  actually  one  and  one  half  quarters)  was 
devoted  to  software  systems  development 

The  first  course  was  designed  to  concentrate  on  maintenance.  Specifically,  the 
class  was  organized  into  two  chief  programmer  teams  as  described  by  Brooks 
[Brooks  82].  Team  concepts  and  organizational  issues  were  presented.  Students 
were  then  able  to  choose  a  role  to  play  in  the  team  effort  using  die  team  member 
positions  described  by  Tomayko  [Tomayko  87A,  Tomayko  87B].  The  teams  were 
provided  an  artifact,  selected  fiom  among  those  provided  by  the  Software 
Engineering  Institute  (SEI),  and  all  of  the  associated  development  documents 
consisting  of  many  of  the  deUverables  required  under  DOI>STD  2167A.  This 
artifact  was  used  to  perform  selected  enhancements  and  corrections.  This  was 
accomplished  by  having  the  students  form  a  diange  control  board  and  providing 
the  board  a  series  of  change  requests  and  discrepancy  reports.  A  budget  was 
also  provided  to  the  team  project  administrator  with  cost  codes  for  the  various 
activities  that  the  students  performed  and  dollar  amoimts  allocated  for  each  cost 
code.  The  students  then  selected  vduch  diange  requests  and  disaepancy  reports 
to  accept  based  upon  technical  and  budgetary  considerations.  They  dien  had  to 
perform  the  maintenance  effort  and  deliver  the  product 

To  implement  this  course  design,  we  started  the  dassroom  instruction  as  a 
traditional  software  engineering  overview,  introducing  life  cyde  models  and 
discussing  issues  that  pertain  to  life  cyde  phases.  This  was  initially  augmented 
in  the  laboratory  by  providing  team  building  exercises.  The  Psychology 
Department  at  Florida  Tech  supplied  us  with  some  exerdses  that  are 
traditionally  used  to  foster  team  building.  We  had  our  students  complete  the 
exercises  as  part  of  their  laboratory. 

Classroom  instruction  meanwhile,  continued  wifii  a  detailed  discussion  of  each 
phase  of  the  life  cyde.  Issues  in  requirements  gathering  and  analysis  were 
examined  and  discussed,  followed  by  specifications,  design,  implementation. 


testings  and  maintenance.  Each  topic  was  expanded  to  provide  the  student  with 
a  badcground  to  fulfill  their  portion  of  the  lalwratory  exercises. 

The  laboratory  exercises  were  designed,  after  the  initial  team  building  phase,  to 
provide  the  students  with  as  dose  to  a  "real  world"  experience  as  is  possible  in 
an  academic  setting.  Toward  that  end,  the  maintenance  exercises  described  in 
the  Software  Engineering  Institute  Educational  Materials  [Engle  89A]  were 
provided  as  a  latoratory  artifact  The  actual  artifact  is  approximately  lO/KX) 
source  lines  of  code  in  Ada.  Exercises  are  described  in  that  report  on  how  to 
change  the  artifact  to  provide  new  functionality  (perfective  maintenance)  and 
how  to  correct  known  defidendes  (corrective  maintenance).  In  addition,  the 
artifact  as  written  to  run  on  a  VAX  computer  under  the  VMS  operating  system. 
Our  students  ran  it  on  a  SPARC  using  Unix.  This  meant  that  some  environment 
changes  had  to  be  provided  (adaptive  maintenance).  However,  this  was  not  the 
interesting  part.  What  constituted  a  new  approach  was  that  die  students  were 
divided  into  two  teams,  each  of  which  had  positions  that  are  normally  found  in 
software  development  (and  thus  maintenance)  teams  in  software  development 
organizations.  Specifically,  one  student  was  chosen  to  be  in  the  role  of  die  task 
leader,  another  was  the  project  administrator,  another  was  the  configuration 
manager,  another  was  qu^ty  assurance,  etc  The  choice  was  open  to  the  student 
who  interviewed  for  the  position  desired.  The  interviews  were  videotaped  (with 
the  student's  permission)  and  the  student  was  provided  with  a  critique  of  dieir 
interview  as  a  guide  for  when  they  will  be  interviewing  for  "real"  jobs.  An 
approach  modeled  on  one  describe  by  Dr.  James  Tomayko  at  the  graduate 
level,  was  adopted  (see  "Teaching  a  Project-Intensive  Intrcxluction  to  Software 
Engineering"  [Tomayko  87A,  Tomayko  8^]). 

After  one  and  one  half  quarters,  the  students  delivered  an  improved  version  of 
the  original  artifact  Di^very  included  reviews  and  inspections  of  both  the 
design  and  the  implementation. 

The  second  course  was  designed  to  concentrate  on  software  systems 
development  The  students  were  again  working  in  teams,  but  tius  time  they  did 
not  have  an  artifact  upon  which  to  base  their  work.  Instead,  they  were  provided 
a  requirements  document  containing  tiie  usual  set  of  ambiguities  associated  witii 
using  the  English  language  as  a  descriptor,  fi-om  which  they  were  to  create  a 
specification  for  the  system  to  be  developed.  A  Qeanroom  Software  Engineering 
approach  was  taught,  with  the  student  teams  divided  into  three  units  each, 
consisting  of  a  specification  unit,  a  design  and  implementation  unit,  and  a 
certification  unit  The  specifications  aeated  tiie  students  were  turned  over  to 
the  design  and  implementation  unit,  that  used  box  structured  design  techniques 
to  create  a  design  that  was  subjected  to  preliminary  design  reviews  and  critical 
design  reviews  with  the  whole  class  participating.  Actual  implementation  of  the 
system  was  not  likely  due  to  time  constraints,  but  all  software  system 
development  activities  up  to  implementation  were  to  be  carried  out  by  the 
students. 


The  implementation  of  this  second  half  design  of  the  year  long  curriculum 
included  a  new  development  project  conducted  under  the  Cleanroom  approach 
to  software  development  In  this  portion  of  the  course/  the  students  developed  a 
prog;ram  to  manipiilate  a  robotic  arm  provided  to  them.  Originally,  the  arm  was 
to  coimected  to  a  port  on  the  SPARC  machine  provided  for  their  use.  When 
the  students  were  unable  to  manipulate  the  robot  through  the  SPARC  port,  they 
decided  to  switch  platforms  and  manipulate  the  arm  tlvough  the  port  on  a  PC. 
This  decision  was  made  only  after  a  careful  analysis  of  their  alternatives  and  the 
cost-tradeoffs  involved.  Although  the  robotic  arm  never  did  complete  its 
a^/Signed  purpose,  the  learning  experience  of  the  students  was  very  positive. 

After  the  experiences  of  this  first  time  teaching  the  course  in  this  format,  we 
evaluated  our  students  to  compare  them  against  students  taught  using  prior 
curricula.  It  was  a  subjective  assessment  but  the  instructors  unanimously  felt 
that  the  students  were  strong  in  team  cooperation  skills  and  in  their 
imderstanding  of  the  controlling  disciplines  (configuration  management  quality 
assurance,  verification  and  validation,  etc.),  but  they  were  too  weak  in 
programming  and  in  data  structures.  Accordingly,  we  modified  the  entire 
program  for  ^e  next  year.  This  caused  us  to  delay  the  submission  of  this  report 
imtil  the  results  of  that  modification  were  assessed. 

In  the  second  version  of  the  curriculum  for  sophomores,  we  spent  the  first 
quarter  and  a  half  teadiing  die  students  fundamental  data  structures  to  correct 
the  perceived  deficiency  fiom  the  first  iteration.  This  built  upon  their  earUer 
foimdations  in  programming-in-the-small.  The  students  then  performed  a 
software  development  exercise  using  a  surgical  team  approach  (as  discussed  in 
[Brooks  82],  but  with  a  smaller  artifact  The  results  were  very  encouraging. 

The  first  iteration  used  the  SunAda  compiler  on  the  SPARC  and  the  Meridian 
Ada  compiler  on  the  PC.  The  second  iteration  used  solely  the  Meridian  Ada 
compiler  on  the  PC  Cadre  Teamwork  was  obtained  for  use  by  the  students,  but 
was  deemed  too  difficult  to  use  by  this  level  of  student  Thus,  only  instructor 
demonstrations  of  its  potential  were  provided  for  the  students. 

IV.  Conclusions 

Our  first  attempt  to  radically  change  the  curriculum  might  be  described  as  too 
much  too  soon.  It  had  several  deficiencies  and  was  not  appropriate  for  further 
dissemination.  We  then  decided  to  modify  this  approach  and  restructure  the 
curriculum  to  correct  obvious  short-comings.  c5ur  second  iteration  of  this 
curriculum  provides  for  a  more  traditional  approach  for  the  first  semester 
(although  out  of  the  normal  sequence  for  a  data  structures  course),  and  the 
innovative  portion  is  more  or  less  restricted  to  the  second  semester.  CV  course, 
this  presupposes  a  radically  different  first  year,  vdiich  our  program  continues  to 
use.  The  results,  in  terms  of  lesson  plans  and  course  material,  are  probably  not 


iisable  at  many  other  institutions.  Since  our  program  is  so  vinique  and  the 
situations  we  encountered  are  so  very  different  than  traditional  programs,  this 
curriculum  will  not  likely  be  of  use  to  other  institutions.  Therefore,  we  will 
provide  information  on  request  to  interested  organizations,  but  will  not 
disseminate  this  material  widdy.  Our  experiences  have  been  disappointing,  but 
the  effort  has  not  been  wasted.  Many  lessons-leamed  were  obtained  that  have 
already  proved  valuable  and  no  doubt  will  continue  to  prove  valuable  in  the 
future. 
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